home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 2 / CU Amiga Magazine's Super CD-ROM 02 (1996)(EMAP Images)(GB)[!][issue 1996-04].iso / magazine / amiga_e / amigae.june.archive / 000109_crash!mars.let.uva.nl!wouter_Thu, 17 Jun 93 19:52:12 PST.msg < prev    next >
Text File  |  1993-08-31  |  4KB  |  111 lines
  1. Received: by bkhouse.cts.com (V1.16/Amiga)
  2.     id AA00000; Thu, 17 Jun 93 19:52:12 PST
  3. Received: from mars.let.uva.nl by crash.cts.com with smtp
  4.     (Smail3.1.28.1 #15) id m0o6WFq-00011UC; Thu, 17 Jun 93 19:32 PDT
  5. Received: by mars.let.uva.nl id AA03653
  6.   (5.65c/IDA-1.4.4 for amigae@bkhouse.cts.com); Fri, 18 Jun 1993 04:35:44 +0200
  7. Return-Path: <wouter@mars.let.uva.nl>
  8. Date: Fri, 18 Jun 1993 04:35:44 +0200
  9. Message-Id: <199306180235.AA03653@mars.let.uva.nl>
  10. X-Organisation: Department of Computational Linguistics,
  11.                 University of Amsterdam
  12.                 Spuistraat 134, 1012 VB Amsterdam, The Netherlands
  13. From: Wouter van Oortmerssen <wouter@mars.let.uva.nl>
  14. To: amigae@bkhouse.cts.com
  15. Subject: linked lists and labels
  16.  
  17. >> I always thought Linked Lists were a bit like linked records or linked lists
  18. >> in C (I not too sure using C). The general gist is that it's an object with a
  19.  
  20. >> extra field called next which contains a pointer to the next structure, which
  21. >> E does automatically. How does E do Link(a,b) when a,b are strings and what
  22. >> does it mean to have to linked strings.. I don't know.
  23.  
  24. A [] structure is not linked: it's a linear structure like arrays etc.
  25. The next field in a STRING is something specific to this datatype,
  26. if you want the general form of a linked list, you'll need to make an
  27. object:
  28.  
  29. E:            C:            Pascal:
  30.  
  31. OBJECT bla        struct bla {        TYPE bla=RECORD
  32.   next, otherdata      int next, otherdata;      next, otherdata:INTEGER
  33. ENDOBJECT        };            END;
  34.  
  35. otherdata should be the data you would actually like to store in the
  36. list. for linking you cannot use Link(), as this is for STRINGs only.
  37.  
  38. however you can make your own:
  39.  
  40. PROC linkbla(current:PTR TO bla,next)
  41.   current.next:=next
  42. ENDPROC
  43.  
  44. PROC nextbla(current:PTR TO bla) RETURN IF current THEN current.next ELSE NIL
  45.  
  46. etc.
  47. better use x.next:=y etc. directly, ofcourse.
  48.  
  49. >> > that's all very nice, but remember you're making a non-standard
  50. >> > extension to the language... the fact that EC accepts your arrays of
  51. >> > lenght 0 is pure luck: I don't support this for any future releases.
  52. >> > (EC accepts it because it assumes the modules to be correct)
  53. >> > 
  54. >> > Wouter
  55. >> 
  56. >> I kinda realised it was sorta breaking the structure, but it works! I didn't
  57.  
  58. "it works!" is about the worst attitude towards programming I know. :-)
  59.  
  60. >> think it'd hurt too much as the '.i' files contain pretty much the same thing
  61. >> , just look at dosasl.i, anyhow if you'renot gonna officially support it how
  62. >> about putting a LABEL directive in the modules. It's kinda standard to use
  63. >> anchor.buf for the filename, if you have to use anchor+SIZEOF anchorpath,
  64. >> it makes E a bit more primitive to use.
  65.  
  66. E, is a higher programming language, and it simply doesn't allow
  67. for these labels like assembly. if you really want, then just change
  68.  
  69. LABEL ap_buf
  70.  
  71. in the .i file to 
  72.  
  73. STRUCT ap_buf,1
  74.  
  75. and convert with the original version of Iconvert. You'll get exactly
  76. the same thing as in C (see: dosasl.h), and it will let you address
  77. with "anchor.buf"
  78. but: don't go about changing thing which might affect compiler
  79. behaviour like you did before. my warning should be enough.
  80.  
  81. >> Son Le
  82.  
  83. >> >...non-standard extension to the language... the fact that EC accepts your
  84. >> >arrays of length 0 is pure luck...
  85. >> 
  86. >> Wouter, let me make sure we understand each other.  I assume you looked at th
  87.  
  88. >> arpbase.i include.  I was under the impression that this LABEL ap_Buf was 
  89. >> *supposed* to be part of the STRUCTURE AnchorPath!  Are you saying it is not
  90.  
  91. just look at the C version... the assembly one is just a hack.
  92.  
  93. >> really part?  If so, why?  According to the Arp manual I'm supposed to be abl
  94.  
  95. >> to access this by name.  If it's not in the module's OBJECT definition, then 
  96. t
  97. >> won't exists (unless the storage is still there due to longword padding.)  Am
  98. >> I right?  (Eesh!  I hope I am 'cause I thought we had a good solution :)
  99.  
  100. If _that_ is you idea of a good solution...
  101. anyway, check with what I propose in the answer to Son Le above:
  102. and all that without dangerous manipulations!
  103.  
  104. >> Later.  -- Barry
  105.  
  106. Wouter
  107.  
  108.    ____  Wouter van Oortmerssen, Wouter@alf.let.uva.nl
  109.   / __/  "Einen Satz verstehen, heisst, wissen was der Fall ist,
  110.  / __/    wenn er wahr ist" - Wittgenstein
  111. /___/  ->subscribe to the E mailing list: amigae-request@bkhouse.cts.com<-